feat: add feedback edges#73
Conversation
for feedback
✅ Deploy Preview for hydraflow ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
solsarratea
left a comment
solsarratea
left a comment
There was a problem hiding this comment.
niiiiiit :3
have 2 comments:
- don't understand what a cycle is now (for cycle detection algorithm), couldn't build an example, does it even have sense to still check this?
- for future discussion: not following exactly the role of
delayFrame.. would work by creating N buffers? would only save a frame every N-executing cycles?
|
Good points. The main concept introduced in the PR is the 'delay edge', an edge that sends the previous frame. With this, we can legally create cycles, allowing us to do all the nice feedback things we would want to do with Hydra. So now we now have two edges: normal edges (which send the current frame) and delay edges (which send the previous frame). What is a cycle? Before we checked cycles in the graph. Now we check cycles in the 'same-frame' dependency graph (i.e. ignoring delay edges). A cycle error is now: a directed cycle containing only normal edges. Example: A -> B, B -> A (normal) is an error; A -> B (normal), B -> A (delay) is allowed feedback. What is delayFrames? Currently, delay edges only support sending the previous frame. I put in delayFrames in case we want to extend to sending the frame n before the current one. I haven't thought much about if we would want that or how to best implement it! What I propose
|
|
I think I'll also rename 'delay edge' to 'feedback edge'. I know I was big on the 'delay' concept earlier, but playing around with it, 'feedback' feels more intuitive for a user. You support that? |
|
agree with renaming on feedback edge :) i still can't think of a scenario where this A -> B, B -> A will happen without creating a feedback edge, making me doubt if we even need to check for cycles. but still agree "same-frame cycle detection" is better naming |
|
A -> B, B -> A without a feedback edge is bad. We check for that and error if it happens. We need to check that to validate that we are building good graphs. However, I've made it neater for users so that creating A -> B, B -> A automatically creates a feedback edge, as that is what I presume they want to happen. So, whilst a user would struggle to create an invalid cycle in the UI, it's important that we check for it so we're sure we're building valid graphs. |
2 participants
No description provided.